\section{Architectural Patterns for Distributed Computing}

Der Artikel „Architectural Patterns for Distributed Computing“ dreht sich um Architektur Patterns die von
 der „Microsoft’s Service Oriented Architecture Maturity Model“ kurz  SOAMM mit und für Kunden entwickelt
  wurden. Diese Patterns wurden im Zuge echter Problemstellungen herausgearbeitet und entwickelt.
   Im Anschluss wurden die Patterns mit der aktuellen Technologie implementiert und finden ihre Anwendung
    unter anderem im .NET-Framework.

\subsection{Service Design}

Beim Aufbau der Architektur von Services und Geschäftsprozessen wird als wichtiger Punkt festgelegt
dass die Geschäftslogik abgekoppelt vom Interface sein musste. Damit sich Interface und die Service
dahinter eigenständig entwickeln können. Das dazu angewandte SOA Konzept sagt aus dass die Services
eindeutige Grenzen haben und Interaktionen über definierte Nachrichten stattfindet. Weiterhin muss
der Service gewährleisten, dass die Nachrichten geprüft werden. Sie können fehlerhaft oder gar
bösartig sein. Ebenso muss gewährleistet sein, dass der Service robust gegenüber Fehlern ist.
Das „Message Validator“ Pattern beschreibt verschiedene Möglichkeiten eine Nachricht, priorisiert
abhängig von der Geschäftslogik, zu validieren. Ein zweites Pattern, das „Exception Shield pattern“,
beschreibt Vorsichtsmaßnahmen die ein Service Autor einplanen kann um Exceptions abzufangen,
behandeln und zum Klienten zurück zu senden. Wobei gleichzeitig Informationen über die 
Exception geloggt werden können um später eine Fehlersuche zu erleichtern. Als dieser Service in Betrieb
 genommen wurde, standen viele Kunden vor dem Problem, dass man externe
Zugriffe nicht direkt auf die Services zugreifen lassen wollte. Oft waren Unternehmensrichtlinien so
ausgelegt, dass eine direkte Verbindung ins interne Netz von außen nicht zulässig war. Die Lösung zu
diesem Problem war ein Perimeter-Router der die Schnittstelle vom internen Netzwerk zu den externen
Servicenutzern bildete.

\subsection{Process Design}

Das Ziel eines IT Systems ist es die Logik von Geschäftsprozessen abzubilden. Mit der steigenden
Automatisierung von Geschäftsprozessen durch die IT Abteilungen bekommen diese immer mehr an
Verantwortung. Die Markt Position eines Unternehmens kann dadurch von der Effektivität der IT, 
neue Geschäftsprozesse umzusetzen, abhängen. Es gilt daher die Softwareentwicklung, sei es das
Design oder die Implementierung, zu optimieren. Bestenfalls gibt es die Möglichkeit, auch für
Personen ohne Programmierkenntnis, mittels grafischer Tools Geschäftsprozesse zu ändern und
zu erstellen. Dazu aber wird eine Umgebung gebraucht, die diese Prozesse lesen, verarbeiten
und auch umsetzen kann. Zusätzlich sollte die Umgebung beständig, fehlertolerant und
möglichst plattformunabhängig sein.

\subsubsection{Key Functional and Nonfunctional Characteristics}

Die Erfahrung zeigt dass folgende Punkte durch ein Geschäftsprozess-Design und eine Infrastruktur abgedeckt sein sollten:

\begin{Itemize_small}
  \item Komposition von Geschäftsprozessen und  Integration der Backendsysteme
 \item Smarte Interaktion von Klienten mit der Infrastruktur
 \item Dialogfähigkeit von Prozessen
 \item Zusammenbringen von Analysten und Entwicklern durch prozessgetriebene Entwicklung
 \item Reduktion von Änderungsanträgen
 \item Online/Offline Support auf Prozessebene
 \item 	Groß angelegte Konfigurations und Managementmöglichkeiten
 \item Regeln vom Prozesscode trennen zur Verbesserung der Flexibilität
\end{Itemize_small}

\subsubsection{Patterns}

Folgende Patterns wurden zusammengetragen die zusammenhängen mit der Entwicklung von Geschäftsprozessen:

\begin{Itemize_small}
\item Basic Workflow Patterns: control-flow, resource, data, and exception-
handling related Patterns.
\item Advanced Workflow Patterns: wizard-based tools that drive
contract-first development, inclusion of transparent processes or
intermediaries, context-based process selection, enabling stateful
interactions, and externalization of business rules. Some of these
patterns are not formalized elsewhere.
\item Workflow Hosting Patterns: a flexible hosting platform exposing
workflows as web services, locating and selecting business processes
from a repository based on context, scalable process execution
environment, and pluggable workflow runtimes.
\item Business Activity Monitoring: monitoring the current state of a
business activity.
 
\end{Itemize_small}

\subsection{Deploying Service}

Einen Service in Betrieb zu nehmen ist nicht einfach. Es muss entschieden werden wie der Service eingebunden wird, 
wer Zugang dazu hat, welche Protokolle unterstützt werden und wie versioniert wird. In machen Fällen ist es nicht
gestattet dass externe Zugriffe direkt auf die interne IT ausgeführt werden dürfen.

\subsubsection{Patterns}

\begin{Itemize_small}
\item Perimeter Service Router; Gateway zwischen extern und intern
\item Service Catalogue; Extraktion und Speicherung von service-related metadata
\item Service Virtualization; Zusammenführung von Services unter einem virtuellen
\item Service Versioning; Ermöglicht es verschiedene Versionen gleichzeitig zu fahren
\item Service Activity Monitoring; Zentrale Überwachung von Kundeninteraktionen mit dem Service
\end{Itemize_small}

\subsection{Consumption of Services}

Die Nutzung von Services benötigt eine Plattform die sie verbindet. In diesem Zusammenhang wird oft der Enterprise Service Bus (ESB) genannt.
Er unterstützt eine Vielzahl an Mustern.

\subsubsection{Patterns}

\begin{Itemize_small}
\item Message routing patterns
\begin{Itemize_small}
\item Routing Slip Pattern: Nachrichten Routing
\item  Recipient List Pattern: Nachrichten Routing bei einer dynamischen Liste von Empfängern
\item  Content-Based Router: Nachrichten Routing auf Basis des Inhalts
\item  Scatter-Gather: Kommunikationsmanagement bei Multicasts mit Antworten
\item  Repair and Resubmit: Reparatur von fehlerhaften Nachrichten und resend
\end{Itemize_small}
\item Message transformation patterns
\begin{Itemize_small}
\item Data Transformation: Nachrichten semantisch gleichen Formats transformieren
\item Content Enricher: Zusätze Informationen eines anderen Systems in Nachricht inkludieren
\end{Itemize_small}
\end{Itemize_small}

\subsection{Service Administration}

Service Administration beinhaltet die Ebenen Management, Leitung und Ausführung. Verteilte Systeme heute gelten als
gut verstanden und funktionsfähig. Voraussetzung ist aber, dass diese Systeme in einer kontrollieren Umgebung, wie einem 
einzelnen Rechenzentrum aufgestellt sind. Mit dem Internet und Web 2.0 ändert sich dieser Zustand, da man auf
Technologien von Drittanbietern zurückgreift und damit sein eigenes System ins Netz hinaus erweitert. 

\subsubsection{Patterns}

\begin{Itemize_small}
\item Exceptions are unavoidable: Fehler immer akzeptieren; Recovery Methoden einplanen
\item Collecting metrics and logs: Information über Fehler und Performanz sammeln um Fehler- und Schwachstellen Suche zu erleichtern
\item Automate everything: Automatisierung vermeidet Menschen als Fehlerquelle
\item Complex environment factors: Verteilte Systeme agieren untereinander mit einer Vielzahl verschiedener Systeme; Beachtung
von Netzwerkfehlern, Latenz,  
\end{Itemize_small}


\subsection{Conclusion}

In diesem Artikel werden einige Patterns genannt, die während der Arbeit an verteilten Systemen betrachtet wurden.
Es ist wichtig, dass Produkte mittels Patterns designt und erklärt werden. Ohne diese Vorgehensweise wird es schwierig
auf neuere Technologien zu setzen.  Die beschriebenen Patterns werden angeboten durch Produkte von Microsoft wie: DCS, ESBG, WSSF, WCF und mit dem 
Release von Oslo werden die Preise dazu sinken. 